Root cause

In the last week, //rs/tests/node:guestos_no_failed_systemd_units flaked twice
on master / PR branches. In both cases the assertion in
rs/tests/node/guestos_no_failed_systemd_units.rs:40 panicked because
systemctl list-units --failed on the GuestOS node reported:

● reload_nftables.service loaded failed failed Reload nftables when the configuration changes

reload_nftables.service is a path-activated Type=oneshot unit that runs
nft flush ruleset && systemctl reload nftables.service whenever the
orchestrator-generated /run/ic-node/nftables-ruleset/nftables.conf changes.
A previous fix (#9857) added After=nss-lookup.target because
nft resolves the hostos hostname via the nss_icos NSS plugin and would
fail with "Could not resolve hostname" if name resolution wasn't ready yet.

That ordering is necessary but not sufficient: any transient failure of
systemctl reload nftables.service (e.g. nftables.service momentarily
restarting, a brief nss_icos hiccup) leaves this oneshot unit stuck in the
failed state. Because the unit is purely path-activated and the orchestrator
only rewrites nftables.conf on content change, there is no automatic retry,
so the failure persists until the next content change — long enough for the
test assertion to observe it.

Fix

Retry the reload up to 5 times with a 2s sleep in between. This absorbs
transient failures and lets the unit finish successfully without changing the
overall semantics (still Type=oneshot, still triggered by the path unit).

Verification

Ran 3 parallel iterations locally; all passed:

bazel test --test_output=errors --runs_per_test=3 --jobs=3 \\
  //rs/tests/node:guestos_no_failed_systemd_units
# 1 of 1 test passed (3 runs).

PR was created following the steps in .claude/skills/fix-flaky-tests/SKILL.md.